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(57) An apparatus and method provide flexible and 
heightened security for accessing web resources with a 
client browser (100), where the web resources are on a 
server (31). In particular, the apparatus and method are 
accomplished by having the client browser (1 00) gener- 
ate a token that is provided to a security server (140) to 
provide third party validation of a client request for serv- 
ice. The client browser (100) makes a call for service, 
and includes the token as a argument of the call. A CGI- 
BIN program (1 60) that receives the call for service also 
receives the service identifier and arguments, among 
which is the client browser (100) generated token. The 
CGI-BIN application program (160) establishes a con- 
nection to the security server (1 40), and then sends the 
token received as an argument to the security server 
(140) for third-party verification. If the token is verified 
by the security server (140), then the CGI-BIN applica- 
tion program (160) executes the requested service pro- 
gram. 
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Description 

BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 

[0001] The present invention generally relates to 
computers and software, and more particularly, to secu- 
rity involved in accessing a web resource on a server 
with a client browser. 

DESCRIPTION OF RELATED ART 

[0002] As known in the art, the I nternet is a world-wide 
collection of networks and gateways that use the TCP/ 
IP suite of protocols to communicate with one another. 
At the heart of the Internet is a backbone of high speed 
data communication lines between major nodes or host 
computers consisting of thousands of commercial gov- 
ernment educational and other computer systems that 
route data and messages. 

[0003] World Wide Web (WWW) refers to the total set 
of interlinked hypertext documents residing on hypertext 
transfer protocol (HTTP) servers all around the world. 
Documents on the WWW, called pages or web pages, 
are written in hypertext mark-up language (HTML) iden- 
tified by uniform resource locators (URL) that specify the 
particular machine and pathname by which a file can be 
accessed and transmitted from node to node to the end 
user under HTTP. A web site is a related group of these 
documents and associated files, scripts, subproce- 
dures, and databases that are served up by an HTTP 
server on the WWW. 

[0004] Users need a browser program and an Internet 
connection to access a web site. Browser programs, al- 
so called "web browsers," are client applications that en- 
able a userto navigate the Internet and view HTML doc- 
uments on the WWW, another network, or the user's 
computer. Web Browsers also allow users to follow 
codes called "tags" imbedded in an HTML document, 
which associate particular words and images in the doc- 
ument with URLs so that a user can access another file 
that may be half way around the world, at the press of 
a key or the click of a mouse. 

[0005] These files may contain text (in a variety of 
fonts and styles), graphic images, movie files, and 
sounds as well as java applets, perl applications, other 
scripted languages, active X-controls, or other small im- 
bedded software programs that execute when the user 
activates them by clicking on a link. Scripts are applica- 
tions that are executed by a HTTP server in response 
to a request by a client user. These scripts are invoked 
by the HTTP daemon to do a single job, and then they 
exit. 

[0006] One type of script is a common gateway inter- 
face (CGI) script. Generally, a CGI script is invoked 
when a user clicks on an element in a web page, such 
as a link or image. CGI scripts are used to provide in- 



teractivity in a Web page. CGI scripts can be written in 
many languages including C, C++, and Perl. A CGI-BIN 
is a library of CGI scripts applications that can be exe- 
cuted by a HTTP server. 
5 [0007] A key difficulty with access to these documents 
and associated files, scripts, subprocedures, and data- 
bases that are served up by an HTTP server on the 
WWW is that of security. How does one ensure that only 
allowed users from allowed client systems are permitted 
access to the server application and also ensure that 
access cannot be perverted to malicious purposes? 
[0008] The method currently being used involves use 
of a "cookie." Cookies are blocks of data that a server 
returns to a client in response to a request from the cli- 
ent. The block of data is then stored on a client's system. 
When the client returns to the same web site, the client 
sends a copy of the cookie back to the server, thereby 
identifying the client to the server. Cookies are used to 
identify users, to instruct the server to send a custom- 
ized version of the requested web page, to submit ac- 
count information for the user, and for other administra- 
tive purposes. On most systems, a cookie program is 
run during user logon. 

[0009] The prior solution for providing security when 
accessing web resources suffers from the following se- 
curity weaknesses. It will be shown later howthe present 
invention addresses and overcomes certain of these dif- 
ficulties. 

[0010] A problem with the prior solutions is that the 
host addresses and user names (i.e., user logon infor- 
mation) are sent in plain text that is very open to "spoof- 
ing". A knowledgeable hacker can transmit packets pre- 
tending to be from another machine or another user to 
thereby gain unauthorized access to the server. 
[0011] Yet another problem arises when multiple lev- 
els of user security are attempted. The cookie method 
only allows a single level of security. Moreover, the use 
of cookies does not allow for a user application to be 
integrated with a security system. Currently, cookies are 
part of the client browser program and are separate from 
a user application. 

[0012] Another problem in the prior art is that the au- 
thentication is weak. This is because the server accepts 
the user and host name as identified in the transmission 
without proof. Furthermore, there is a problem in that no 
state is maintained since each command transaction 
stands alone. This leaves these methods open to "re- 
play attacks" wherein a hacker captures a valid network 
packet, alters some details (like the name of the user or 
the command to execute) and resends it. 
[0013] However, until now, network systems have 
lacked the ability to provide flexible and heightened se- 
curity for web documents on the Internet or other types 
of networks. 

SUMMARY OF THE INVENTION 
[0014] Certain objects, advantages, and novel fea- 



rs 



20 



25 



30 



35 



40 



45 



50 



2 



3 



EP0 952 717 A2 



4 



tures of the invention will be set forth in part in the de- 
scription that follows and in part will become apparent 
to those skilled in the art upon examination of the fol- 
lowing or may be learned with the practice of the inven- 
tion. The objects and advantages of the invention may 
be realized and obtained by means of the instrumental- 
ities and combinations particularly pointed out in the ap- 
pended claims. 

[001 5] To achieve the advantages and novel features, 
the present invention is generally directed to an appa- 
ratus and method for providing flexible and heightened 
security for accessing web resources with a client 
browser where the web resources are on a server. 
[0016] In accordance with one embodiment of the 
present invention, a client user interface (browser) gen- 
erates a token. That token is sent to a security server to 
provide third party validation of a client user request for 
service. The client user interface then makes a call to a 
server application for service, and the client user inter- 
face sends with the call to the server application the to- 
ken as an argument of the call for service. 
[001 7] The server application receives the request for 
service from the client user interface and then performs 
its own login authorization of the client user. If the au- 
thorization is okay then it performs a call to the required 
CGI-BIN application program for the requested service. 
[0018] The CGI-BIN program called for the requested 
service receives the requested service identifier and ar- 
guments among which is the client user interface gen- 
erated token. The requested program establishes a con- 
nection to the security server, and then sends the token 
received as an argument to the security server for veri- 
fication. 

[001 9] The security server receives the token for ver- 
ification from the requested program and verifies the to- 
ken received from the requested program with the token 
received from the client user interface. If the tokens 
match, then the security server returns to the requested 
program the indication that the token is verified. Upon 
verifying a token for a requested user program, the se- 
curity server returns to the state of waiting to receive a 
token from a client user interface. 
[0020] The requested program then executes the re- 
quested program and sends the output to the server ap- 
plication before exiting. The server application receives 
the output from the requested program and returns the 
data to the client user interface (browser) for display to 
the client user at which point the server application re- 
turns back to the state of waiting for a request for service 
from a client user interface. 

[0021] In accordance with another embodiment of the 
present invention, multiple levels of user security and 
are implemented for protection of web resources. 
[0022] In accordance with yet another embodiment of 
the present invention, an apparatus and method for im- 
plementing and securing web resources provide for a 
user application integrated security system. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0023] The accompanying drawings incorporated in 
and forming a part of the specification illustrate several 
5 aspects of the present invention, and together with the 
description, serve to explain the principles of the inven- 
tion. In the drawings: 

[0024] FIG. 1 is a block diagram of the client/server 
system utilizing the Internet. 

10 [0025] FIG. 2 is a block diagram illustrating a browser 
program situated within a computer readable medium, 
for example, in a computer system of the client systems. 
[0026] FIG. 3 is a block diagram illustrating a server's 
service application program, the CGI-BIN program and 

is the security server situated within a computer readable 
medium ; for example, in a computer system of the serv- 
er systems. 

[0027] FIG. 4 is a block diagram illustrating the proc- 
ess for client browser, and the server's server applica- 
20 tion, CGI-BIN program, and the security server process- 
es, as shown in FIGs. 2 and 3. 

[0028] FIG. 5 is a flow chart of the process for the cli- 
ent browser of the present invention, as shown in FIG. 4. 
[0029] FIG. 6 is a flow chart of the process for the serv- 
es er's server application of the present invention, as 
shown in FIG. 4. 

[0030] FIG. 7 is a flow chart of the process for the se- 
curity server program of the present invention, as shown 
in FIG. 4. 

30 [0031] FIG. 8 is aflowchart of the process forthe CGI- 
BIN program process of the present invention, as shown 
in FIG. 4. 

DETAILED DESCRIPTION OF THE PREFERRED 



[0032] The present invention will now be described in 
detail with specific reference to the drawings. While the 
invention will be described in connection with these 
drawings, there is no intent to limit it to the embodiment 
or embodiments disclosed therein. On the contrary, the 
intent is to cover all alternatives, modifications, and 
equivalents included within the spirit and scope of the 
invention as defined by the appended claims. 
[0033] Turning now to the drawings, FIG. 1 is a block 
diagram of just one system configuration that illustrates 
the flexibility, expandability, and platform independence 
of the present invention. While the system configuration 
could take many forms, the diagram of FIG. 1 illustrates 
a plurality of diverse workstations 12,14 and 1 6 directly 
connected to a network, for example, but not limited to, 
a LAN 18. Additional workstations 21 , 22 may similarly 
be remotely located and in communication with the net- 
work 18 through a dial-in or other connection 24. Each 
of the workstations in FIG. 1 are uniquely illustrated to 
emphasize that workstations may comprise a diverse 
hardware platform. 

[0034] As is well known, browser applications are pro- 
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vided and readily available for a variety of hardware plat- 
forms. Browsers are most commonly recognized for 
their utility for accessing information over the Internet 
32. As aforementioned, a browser is a device or platform 
that al lows a user to view a variety of service collections. 
The browser retrieves information from a web server 31 
or network server 26 using HTTP, then interprets HTML 
code, formats, and displays the interpreted result on a 
workstation display. 

[0035] Additional workstations 33 and 34 may similar- 
ly be located and in communication with the web servers 
31 for access to web pages on the local server and the 
Internet. Workstations 33 and 34 communicate with the 
web server 31 on a LAN network 35. Networks 18 and 
35 may be, for example, Ethernet type networks, also 
known as 10 BASE 2, 10 BAS 5, 10 BSAF, 10 BAST, 
BASE BAN network, CO-EX cable, and the like. 
[0036] As illustrated in FIG. 2 client systems today 
generally include only a browser program 100 (e.g., Net- 
scape, Internet Explorer or other browser program) for 
use in accessing locations on a network 11. These 
browser programs 100 reside in computer memory 51 
and access communication facilities modem 47 totrans- 
port the user to other resources connected to the net- 
work 11. In order to find a resource, the user should 
know the network location of the resource denoted by a 
network location identifier or URL. These identifiers are 
often cryptic, following very complex schemes and for- 
mats in their naming conventions. 
[0037] Systems today identify, access ; and process 
these resources desired by a user by using the proces- 
sor 41, storage device 42, and memory 51 with an op- 
erating system 52 and window manager 53. The proc- 
essor accepts dataf rom memory 51 and storage 42 over 
the bus 43. Direction from the user can be signaled by 
using the input devices mouse 44 and keyboard 45. The 
actions input and result output are displayed on the dis- 
play terminal 46. 

[0038] The first embodiment of the present invention 
involves the browser program 100. The browser pro- 
gram 100 is the software that interacts with the server 
to obtain the requested data and functionality requested 
by the client user. The client browser program 100 will 
be described hereafter in detail with regard to FIGs. 4 
and 5. 

[0039] Illustrated in FIG. 3 is the architecture of the 
server system 26 and 31. The principal difference be- 
tween the servers 31 and 26 and the clients 12, 16, 21 , 
22, 33 and 34, illustrated in FIG. 1, are that the client 
systems interface to the user and request the function- 
ality through the browser program 1 00, while the servers 
26 and 31 provide the services requested by the client 
systems utilizing the server application program 120, 
the security server 140, and CGI-BIN program 160. 
[0040] Otherwise, the functionality of processor 61, 
storage 62, mouse 64, keyboard 65, display 66, and mo- 
dem 67 are essentially the same as corresponding items 
of FIG. 2 described above. As known in the art, the client 



systems 12, 14, 16, 21, 22, 33 and 34, and server sys- 
tems 26 and 27, may reside on the same physical ma- 
chine. 

[0041] The principal difference in the server is that the 
5 memory 71 interacting with the operating system 72 and 
the window manager 73 provide the services requested 
by the client utilizing the server application 120, CGI- 
BIN program 160, and security server 140. Server ap- 
plication 120, CGI-BIN program 160, and security server 
140 will herein be defined in more detail with regard to 
FIG. 4 and FIGs. 6, 7 and 8. 

[0042] With regard to FIG. 4, the client system 12, 16, 
21 , 22, 33 or 34 can request services from the web serv- 
er 31 by utilizing the client system browser program 1 00. 
The browser user interface program first receives a re- 
quest from the user and checks to make sure that the 
user is authorized to access a particular function. 
[0043] Next, the web browser generates a token by 
utilizing any suitable algorithm and generator. In the pre- 
ferred embodiment, the token is not a sequential 
number, but is in fact a number generated by a random 
number generator. 

[0044] The client user interface browser connects to 
the security server. This connection can be accom- 
plished, for example, by using sockets. The client user 
interface 100 sends the token to the security server 140 
utilizingthe established connection. Next, the client user 
interface browser 1 00 makes a call to the service appli- 
cation for service and sends the token to the server ap- 
plication as one of the arguments for service requested. 
This request for service goes out on a network line to 
the server 31 and is received by the server application 
120. 

[0045] The server application 120 receives a request 
for service from the client user interface 100. Next, the 
server application 120 finds the requested program and 
calls the requested program by invoking CGI-BIN appli- 
cation 160 using the program name and arguments. 
[0046] The CGI-BIN application program 160 re- 
ceives the program name execution arguments. Prior to 
executing the requested subroutine that provides the re- 
quested service, the CGI-BIN program 160 establishes 
a socket with the security server 140. Once the socket 
is established with the security server 140, the CGI-BIN 
application program 160 sends a token verification re- 
quest to the security server 1 40. 

[0047] The security server 140 upon initialization es- 
tablishes a listening socket. The security server 140 
waits to receive a token from the client user interface 
1 00 on the socket established on the connection created 
when the client user 100 was verified. Once a token is 
received from the client user interface, it is added to the 
security server's token verification table. The security 
server 140 waits to receive a token verification request 
from the CGI-BIN program 160 on a CGI-BIN token ver- 
ification socket. When the request to verify a token is 
received from the CGI-BIN program 160, the security 
server 140 checks the token verification table and re- 
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turns a message to the CGI-BIN program 160 as to 
whether or not the token has been received from the 
client user interface and therefore is a valid token. 
[0048] When the CGI-BIN program 160 receives the 
token verification message from the security server 1 40, 
the CGI-BIN program 160 checks the authorization of 
the token. If the token authorization message received 
from the security server 140 is satisfactory, then the 
CGI-BIN program 160 executes the requested opera- 
tion and writes the output to a stdout which is then re- 
turned to server application 1 20. If the token authoriza- 
tion message received from the security server 140 is 
unsatisfactory, then an error message is sent to the 
server application 120. When the output is sent to the 
server application 120, the CGI-BIN program 160 exits 
and therefore ceases to exist. 

[0049] Server application 120 receives the output of 
the CGI-BIN application 160 and the exit status of the 
CGI-BIN application program process 160 and returns 
the output over a network to the client browser program 
100. The browser program 100 then returns the output 
to the application program that requested service in the 
client system 12. This process will be further explained 
hereafter with regard to FIGs. 5-9. 
[0050] The process implemented by the browser pro- 
gram 1 00 in the client system 1 2 is illustrated in FIG. 5. 
The first step of the browser program 100 is to initialize 
the client browser program 1 00 at step 1 01 . The browser 
program 100 then accepts the login of the user name 
and password from the user and creates a connection 
to the security server 1 40 at step 1 02. The browser pro- 
gram 100 receives the request for service from the user 
at step 103. 

[0051] The browser program 100 generates a token 
at step 104. In the preferred embodiment, the token is 
a random number generated from a random number 
generation function. However, it is known in the art that 
there are other methods for generating a unique token 
that can be utilized. 

[0052] The user browser program 1 00 then sends the 
token generated in step 104 to the security server 140 
at step 105. The browser program 100 receives the re- 
quest for service from the user at step 1 03. The browser 
program 1 00 binds to the server application 1 20 at step 
1 06. The browser program 1 00 makes a call to the serv- 
er application 1 20 and sends the token as argument da- 
ta at step 107 to the server application 120. The user 
browser program 1 00 is then suspended until the return- 
ing of data at step 108. 

[0053] When data is returned to the client user inter- 
face, the browser program 100 is unsuspended at step 
88 and the browser program 100 displays the data re- 
ceived from server application 120 to the user at step 
109. The client user interface browser 100 then returns 
to step 103 and waits for the next request for service 
from the user. 

[0054] Illustrated in FIG. 6 is the flow diagram of the 
architecture and process implemented by the server ap- 



plication 120. The server application 120 is initialized at 
step 121. The server application 120 waits to receive a 
client request for service at step 122. 
[0055] When a client request is received at step 1 22, 

s the server application 1 20 determines which application 
program 100 will provide the service requested by the 
client system, and the server application 120 binds to 
the specified CGI-BIN application 160 at step 123. The 
server application 120 invokes the specified CGI-BIN 

10 application 160 with the specified arguments, one of 
which is the token, and sends the necessary data at step 
124. The server application 120 process is suspended 
at step 1 25, until data is received from the specified CGI- 
BIN application 160. 

15 [0056] When the output is received from the specified 
CGI-BIN application 160, the server application 120 re- 
ceives the output at step 1 26. The server application 1 20 
then writes the output received from the CGI-BIN appli- 
cation 160 and returns that output to the client request - 

20 ing service at step 1 27. The server application 1 20 then 
exits that session, loops backtostep 122 ; and suspends 
itself until a new request is received. 
[0057] With regard to FIG. 7 illustrated is shown the 
process of the security server 140. First, the security 

25 server 140 is initialized at step 141. Next, the security 
server 140 accepts a connection from a user browser 
1 00 by getting the user login name and password at step 
1 42. The security server 1 40 then authenticates the user 
name and password. Once the authentication of the 

30 login user name and password is complete, the security 
server 1 40 suspends until it receives a token from a cli- 
ent user interface on the socket connection at step 143. 
[0058] The security server 140 accepts the connec- 
tion socket from the CGI-BI N program 1 60 at step 1 44. 

35 Next, the security server 140 receives a token verifica- 
tion request from the CGI-BIN program 160 on the CGI- 
BIN socket at step 145. The security server 140 verifies 
the token received from the CGI-BIN program on the 
CGI-BIN socket with the token that was received from 

40 the client user interface on a socket at step 143. 

[0059] If the tokens received at step 1 43 matches the 
token received at step 145, then the token verification 
is successful. If the token received from the client user 
interface on a socket at step 143 does not match the 

45 token received from the CGI-BIN program 160 at step 
1 45, then the token verification fails. The security server 
1 40 waits a predetermined period for the token verifica- 
tion request to arrive from the CGI-BI N program 1 60 be- 
fore timing out. Any subsequent token verification re- 

50 quest from the CGI-BI N program 1 60 on a token that is 
timed out results in a token verification failure. 
[0060] The outcome of the token verification task is 
sent to the CGI-BIN program 160 at step 147 and secu- 
rity server 140 closes the CGI-BIN socket created at 

55 step 144. The security server then returns to step 143 
to wait until it receives another token from a user client 
interface. 

[0061] Illustrated in FIG. 8 is the flow diagram for the 
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CGI-BIN application 160. First, the CGI-BIN application 
160 is initialized at step 161. The CGI-BIN application 
160 receives the request for the requested service with 
the program name and arguments, including the token, 
at step 163. The CGI-BIN application 160 establishes a 
socket to the security server 1 40 at step 1 63. In the pre- 
ferred embodiment, a TCP/IP socket is established. 
[0062] The CGI-BIN application 160 sends the token 
received from the server application 120 to the security 
server 140 for verification at step 164. The CGI-BIN pro- 
gram 160 suspends processing until the return of the 
token verification message from the security server at 
step 165. 

[0063] Once the token verification message is re- 
ceived from the security server 1 40, a test is performed 
on the token verification at step 166. If the token was 
verified by the security server 140, then process flows 
to step 167 in which the CGI-BIN program 160 executes 
the requested service program. After the requested 
service program is executed at step 167, the CGI-BIN 
program 160 receives the stdout and standard error 
messages from the requested service program at step 
168. The CGI-BIN program 160 sends the stdout and 
standard error data to the server application 1 20 at step 
169 and then exits at step 172. 

[0064] If the token verification check at step 166 re- 
sults in the token not being verified, then the CGI-BIN 
program 160 sends an error message to the server ap- 
plication 120 indicating that the token verification with 
the security server 140 failed. The CGI-BIN application 
160 then terminates its execution at step 172. 
[0065] In an alternative embodiment, the CGI-BIN 
program 160 sends the security level of the command 
being executed to the security server 1 40 along with the 
token. The security server 160 verifies the token and it 
also checks the security level of the client user 1 00. To 
ensure the security server 140 is checking the right cli- 
ent user 100, the token would consist of the random 
number + the port number of the connection of the user 
interface to Security Server 140. The security level of 
the client user 1 00 is determined at the time the security 
server 140 authenticates the client user 100 on initial 
connection to the security server 140. 
[0066] The foregoing description has been presented 
for purposes of illustration and description. It is not in- 
tended to be exhaustive or to limit the invention to the 
precise forms disclosed. Obvious modifications or vari- 
ations are possible in light of the above teachings. The 
embodiment or embodiments discussed were chosen 
and described to provide the best illustration of the prin- 
ciples of the invention and its practical application to 
thereby enable one of ordinary skill in the art to utilize 
the invention in various embodiments and with various 
modifications as are suited to the particular use contem- 
plated. All such modifications and variations are within 
the scope of the invention as determined by the append- 
ed claims when interpreted in accordance with the 
breadth to which they are fairly and legally entitled. 



Claims 

1 . A method for securing Web resources in a network 
system, the method comprising the steps of: 

5 

generating a token for a client browser 100; 
transmitting the token to a security server 1 40; 
transmitting a request for service and the token; 
providing an application server 160 for receiv- 
10 ing the request for service and the token from 

the client browser 100, 

requesting verification of the token, by the ap- 
plication server 160; 

transmitting the token received by the applica- 
15 tion server 1 60 to the security server 1 40; and 

comparing the token received from the client 
browser 100 and the token received from the 
application server 160. 

20 2. The method of claim 1, further including the step of: 
generating a match notice when the token re- 
ceived from the client browser 100 and the token 
received from the application server 1 60 match, and 
a nonmatch notice when the token received from 
25 the client browser 100 and the token received from 
the application server 160 do not match. 

3. The method of claim 2, further including the step of: 

transmitting the generated notice to the appli- 
30 cation server 160. 

4. The method of claim 3, further including the step of: 

providing the requested service when a match 
notice is received. 

35 

5. The method of claim 1 , wherein the step of gener- 
ating a token further includes the step of: 

utilizing a random number generator to gen- 
erate the token. 

40 

6. A computer system for providing security to web re- 
sources, comprising: 

a client device 1 2 for generating a token; 
45 an application device 1 60 for providing service; 

and 

a security device 140 for verifying the token 
generated by the client device. 

50 7. The client device of claim 6, further comprising: 

a first client mechanism for transmitting the to- 
ken with a request for service to the application 
device 160; and 
55 a second client mechanism for transmitting the 

token to a security server 140 to provide third 
party validation. 
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8. The application device of claim 6, further compris- 
ing: 

a first application mechanism for receiving the 
request for service and the token from the client s 
browser 100; 

a second application mechanism for requesting 
verification of the token for the security device 
140; and 

a third application mechanism for providing the 10 
requested service when a match notice is re- 
ceived. 

9. The security device of claim 6, further comprising: 

15 

a first security mechanism for receiving the to- 
ken from the client browser 100; 
a second security mechanism for receiving the 
application server 160 token from the applica- 
tion server 160; and 20 
a third security mechanism for comparing the 
token received from the client browser 1 00 and 
the token received from the application server 
160. 

25 

10. The security device of claim 9, further comprising: 

a fourth security mechanism generating a 
match notice when the token received from the 
client browser 1 00 and the token received from 30 
the application server 160 match, and a non- 
match notice when the token received from the 
client browser 1 00 and the token received from 
the application server 160 do not match; and 
a fifth security mechanism for transmitting the 35 
notice generated to the application server 160. 
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FIG. 6 
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FIG. 8 



INITIALIZE CGI-BIN PROGRAM 



RECEIVE PROGRAM NAME AND ARGUMENTS 
(INCLUDING TOKEN) 



ESTABLISH SOCKET TO SECURITY SERVER 



SEND TOKEN VERIFICATION REQUEST TO 
SECURITY SERVER 



RECEIVE TOKEN VERIFICATION FROM 
SECURITY SERVER 




IS TOKEN VERIFIED? 
YES 



NO 



EXECUTE REQUESTED SERVICE 
PROGRAM 






RECEIVE ST DO I 


JT AND STDERR 



SEND ERROR 
MESSAGE 



171 



SEND STDOUT TO SERVER 
APPLICATION 



EXIT 



15 



